Industry has invested billions of dollars in developing control system software for a plethora of computer controlled peripheral devices in order to enhance economic productivity. Often, the software is developed to control a single peripheral device. This is particularly so for unique or limited purpose peripheral devices.
In order to control multiple devices, costly modifications to the application software control code are necessary to adapt the software to circumstances requiring the control and coordination of multiple peripheral devices. For example, every parameter and every variable in the control code related to each peripheral would have to be duplicated for each peripheral on a case-by-case basis. It may take weeks to duplicate one variable for each peripheral device and may take years to locate and reconfigure referential commands for each one.
Further, much of the application control code resulted from endless experimentation and empirical data collection over a span of years by artisans that may no longer be available. Once good control code is working properly, modifying it is a dreaded option.
Conventionally, either the application software itself must undergo custom modification, the jump table included with the application software is expanded, or both. In any case, additional cost and complex operational issues result. A jump table is either an array of pointers that point to executable functions or point to an array of machine code jump instructions. If one is dealing with a relatively static set of functions (such as system calls or virtual functions for a class) then this table may be created once. Functions may then be called using a simple index into the array. This may require retrieving the pointer and calling a function or may require jumping to the machine code depending on the type of table used. In the context of controlling a hardware peripheral, the jump is often made to a function in the basic input/output system (BIOS) of the peripheral.
Rewriting a software application to handle multiple peripheral devices is costly. Further, modifying a BIOS or BIOS interface to handle multiple peripheral devices has disadvantages such as data collisions, sharing issues between I/O resources, or requiring the strict structuring of the various BIOSs to operate in lock step. Each of these issues results in a reduction of performance speed or increased cost.
Accordingly, it is desirable to expand the flexibility of existing peripheral applications economically. In addition, it is desirable to simplify the interface between multiple peripheral devices and to streamline its operation. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.